Problem (#737): every conversation cold-starts on OHE

The runtime-api warm matcher (warm_runtime_matches -> clean_env_for_match) does strict env equality (keys and values), and LMNR_* keys are not in KEYS_TO_CLEAN. So if the request env and a warm pool entry differ on any LMNR_* key, the warm runtime is rejected and the conversation cold-starts.

LMNR_BASE_URL / LMNR_FORCE_HTTP / LMNR_PROJECT_API_KEY are always emitted (="" when off) on both sides and match. But PR #692 (ec2c290) wrapped LMNR_HTTP_PORT in charts/openhands/templates/_env.yaml so the request side OMITS it when laminar.httpPort is unset, while the KOTS warm template (replicated/openhands.yaml:356, anchor &lmnr_http_port reused at :625/:913) still always emits it (="" when analytics off):

only_in_warm=['LMNR_HTTP_PORT']  ->  no warm match  ->  cold start

Fix (quick, teammate-endorsed)

Make the LMNR_* env key set identical on the request side and on both warm paths (KOTS and chart-default), in both toggle states:

1. Request side — charts/openhands/templates/_env.yaml: restore LMNR_HTTP_PORT to always-emit ({{ if and .Values.laminar.enabled .Values.laminar.httpPort }}…{{ else }}""{{ end }}), matching the three LMNR_* keys directly above it. This reverts APP-2260: omit LMNR_HTTP_PORT env when httpPort is unset #692's key omission.
2. Chart-default warm config — charts/runtime-api/values.yaml (warmRuntimes.configs[].environment) and charts/openhands/values.yaml (runtime-api.warmRuntimes override): add the full LMNR_* set (=""). Reverting APP-2260: omit LMNR_HTTP_PORT env when httpPort is unset #692 alone would re-break the chart-default/SaaS path (request LMNR_HTTP_PORT="" but chart-default warm had no LMNR_* keys) — which is what APP-2260: omit LMNR_HTTP_PORT env when httpPort is unset #692 originally papered over. Adding LMNR_* here makes the always-emit revert safe for SaaS.
3. KOTS warm template — replicated/openhands.yaml already always-emits all 4 LMNR_* via shared anchors (:354-357 defined, :623-626 + :911-914 reused). Verified consistent; left unchanged.

Why always-passing LMNR_HTTP_PORT="" is safe

OpenHands/openhands/app_server/sandbox/sandbox_spec_service.py:

• AUTO_FORWARD_PREFIXES = ('LLM_', 'LMNR_')
• get_agent_server_env() forwards every LMNR_* var from the pod env as-is, including empty values — no special-casing.

The agent only emits Laminar traces when LMNR_PROJECT_API_KEY is configured, so LMNR_HTTP_PORT="" is inert when Laminar is off — exactly like the other three LMNR_* keys, which already ship "" in the off state.

Render proof (helm template)

Request side (openhands deployment) LMNR_* key set, both states:

• analytics/laminar OFF (default): LMNR_BASE_URL="", LMNR_FORCE_HTTP="", LMNR_HTTP_PORT="", LMNR_PROJECT_API_KEY=""
• laminar ON (httpPort=8000): same 4 keys, LMNR_HTTP_PORT="8000", LMNR_FORCE_HTTP="true", base-url/api-key via valueFrom

Chart-default warm config (runtime-api warm-runtimes-configmap):

• {"LMNR_BASE_URL":"","LMNR_FORCE_HTTP":"","LMNR_HTTP_PORT":"","LMNR_PROJECT_API_KEY":"", …}

=> Request LMNR_* key set == chart-default warm LMNR_* key set in both toggle states. KOTS path is equivalent by construction: the anchors render all 4 to "" when analytics_enabled != 1 (matching the off request env) and to real values + laminar.enabled=true/httpPort=8000 when on (matching the on request env). KOTS replaces the whole warmRuntimes.configs array, so the chart-default LMNR_* additions are inert on the KOTS path.

Chart versions

• openhands 0.7.63 -> 0.7.64
• runtime-api 0.3.11 -> 0.3.12, and repin openhands -> runtime-api dependency to 0.3.12 (per validate-chart-versions)

Follow-up (deliberately deferred)

The cleaner redesign — thread "is Laminar active" consistently through enterprise-server and runtime-api, or harden runtime-api clean_env_for_match to ignore empty/LMNR_* keys — is intentionally left as a later follow-up. This PR is the minimal always-pass fix.

Closes #737